Predicting expansion failures and defragmenting cluster resources

ABSTRACT

The present disclosure relates to systems, methods, and computer readable media for predicting expansion failures and implementing defragmentation instructions based on the predicted expansion failures and other signals. For example, systems disclosed herein may apply a failure prediction model to determine an expansion failure prediction associated with an estimated likelihood that deployment failures will occur on a node cluster. The systems disclosed herein may further generate defragmentation instructions indicating a severity level that a defragmentation engine may execute on a cluster level to prevent expansion failures while minimizing negative customer impacts. By uniquely generating defragmentation instructions for each node cluster, a cloud computing system can minimize expansion failures, increase resource capacity, reduce costs, and provide access to reliable services to customers.

BACKGROUND

A cloud computing system refers to a collection of computing devicescapable of providing remote services and resources. For example, moderncloud computing infrastructures often include a collection of physicalserver devices organized in a hierarchical structure including computingzones, virtual local area networks (VLANs), racks, fault domains, etc.For instance, many cloud computing services are partitioned intoclusters of nodes (e.g., node clusters). Cloud computing systems oftenmake use of different types of virtual services (e.g., computingcontainers, virtual machines) that provide remote storage and computingfunctionality to various clients or customers. These virtual servicescan be hosted by server nodes on a cloud computing system.

As cloud computing continues to grow in popularity, managing differenttypes of services and providing adequate cloud-based resources tocustomers has become increasingly difficult. For example, demand forcloud-based resources often grows over time for certain customers for avariety of reasons. As a result, customers are often requestingallocation of additional resources. With increased demand, however,conventional systems for allocating cloud-based resources oftenexperience failures or expend considerable costs scaling resources toaccommodate deployment expansions and other increases in cloudutilization.

In addition to deployment growth, many customer deployments may expireor decrease over time for a variety of reasons. For example, thelifetime of certain deployment may expire resulting in retirement ofvarious services. Other customers may simply downgrade based on aspecific customer or application experiencing a decrease in demand forcomputing resources. As a result, resource capacity often becomesfragmented across server nodes and clusters of the cloud computingsystem. This fragmented capacity may result in variety of problemsincluding, for example, expansion failures for existing customers aswell as allocation failures for new deployments. Moreover, addressingfragmented capacity by simply adding new server nodes to accommodateexpansions and deployment requests may result in inefficient utilizationof cloud computing resources as well as high computing costs for bothcloud service providers and customers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example environment of a cloud computing systemincluding cluster defragmentation management system in accordance withone or more embodiments.

FIG. 2 illustrates an example implementation in which the clusterdefragmentation management system predicts expansion failures andimplements defragmentation instructions in accordance with one or moreimplementations.

FIG. 3 illustrates an example framework for implementing the clusterdefragmentation management system in accordance with one or moreembodiments.

FIG. 4A illustrates an example framework for predicting expansionfailures in accordance with one or more embodiments.

FIG. 4B illustrates an example framework for generating and implementingdefragmentation instructions in accordance with one or more embodiments.

FIG. 5 illustrates an example series of acts for predicting expansionfailures and implementing defragmentation instructions in accordancewith one or more embodiments.

FIG. 6 illustrates certain components that may be included within acomputer system.

DETAILED DESCRIPTION

The present disclosure is generally related to predicting expansionfailures for deployments on node clusters of a cloud computing system.The present disclosure further relates to proactively preventing futureexpansion failures by defragmenting a capacity of server nodes on thecluster(s) of the cloud computing system. For example, the presentdisclosure describes a cluster defragmentation management system thatproactively determines whether a current set of allocations on a nodecluster is at risk of experiencing expansion failures based on observedutilization data for the node cluster and other features of deploymentsimplemented thereon. The cluster defragmentation management system canadditionally generate and implement defragmentation instructions at anappropriate severity level in accordance with the determined predictionof expansion failures on the node cluster. One or more embodimentsdescribed herein reduce instances of expansion failures while alsodecreasing costs associated with increased hardware overhead.

By way of example, and as will be discussed in further detail below, thecluster defragmentation management system can identify cluster featuresfor a node cluster based on utilization data for the node cluster. Thecluster defragmentation management system can additionally determine oneor more expansion failure metrics for the node cluster based on theidentified cluster features. For example, the cluster defragmentationmanagement system can predict expansion failures for a set ofdeployments on the node cluster based on the cluster features. In one ormore embodiments, the cluster defragmentation management system maygenerate defragmentation instructions applicable to the node cluster,which may include an identified severity of defragmentation that shouldtake place on the node cluster to avoid upcoming expansion failures. Thenode cluster may execute or otherwise implement defragmentation onserver nodes of the node cluster in accordance with one or moreembodiments described herein.

The present disclosure includes a number of practical applications thatprovide benefits and/or solve problems associated with preventingexpansion and other allocation failures on node clusters of a cloudcomputing system. Examples of these applications and benefits arediscussed in further detail below.

For example, conventional systems typically react to expansion and otherallocation failures using a reactive approach to observed failures thathave recently occurred for a set of deployments. Nevertheless, ratherthan waiting until allocation failures have already happened andresponding after the fact, one or more embodiments described hereininvolve a proactive approach to preventing expansion failures. Inparticular, by determining expansion failure metrics that include anexpansion failure prediction for a set of deployments on a node cluster,the cluster defragmentation management system can determine whetherexpansion failures are expected to happen even where no expansionfailures (or a very limited number of expansion failures) have recentlytaken place on the node cluster.

In addition, where conventional systems often implement inflexible andinefficient approaches to preventing various allocation failures, thecluster defragmentation management implements a defragmentation routinebased on specific features of the corresponding cluster to increaseeffective capacity across a variety of node clusters hosting virtualmachines having different workload characteristics. For example, wheremany conventional computing systems attempt to avoid failures byimplementing uniform policies that underutilize available resources inorder to ensure that adequate resources exist for future deploymentsand/or deployment expansions, the cluster defragmentation managementsystem evaluates utilization data on a cluster-by-cluster basis anddetermines a cluster-unique approach to defragmenting computing capacityon the cloud computing system. In this way, the cluster defragmentationmanagement system can increase effective capacity across node clustershaving different characteristics.

In addition, where conventional cloud computing systems often simply addadditional cores and/or servers to a network infrastructure to ensureadequate computing resources, the cluster defragmentation managementsystem increases effective hardware capacity by implementingdefragmentation instructions at an appropriate severity level for therespective cluster(s). For example, rather than simply adding additionalhardware to a network infrastructure to accommodate growing resourcedemand or to ensure an adequate number of available empty server nodes,the cluster defragmentation management system can reduce significantcosts associated with installing and maintaining hardware byimplementing defragmentation policies that accommodate additionaldeployments while decreasing a number of expansion failures on the cloudcomputing system.

As illustrated in the foregoing discussion, the present disclosureutilizes a variety of terms to describe features and advantages of thesystems described herein. Additional detail is now provided regardingthe meaning of some example terms.

For example, as used herein, a “cloud computing system” refers to anetwork of connected computing devices that provide various services tocustomer devices (e.g., client devices, network devices). For instance,as mentioned above, a distributed computing system can include acollection of physical server devices (e.g., server nodes) organized ina hierarchical structure including clusters, computing zones, virtuallocal area networks (VLANs), racks, fault domains, etc. In addition, itwill be understood that while one or more specific examples andimplementations described herein relate specifically to “clusters” or“node clusters” of server nodes, features and functionality described inconnection with one or more node clusters can similarly relate to racks,regions of nodes, datacenters, or other hierarchical structures in whichnetwork devices are grouped together. The cloud computing system mayrefer to a private or public cloud computing system.

As used herein, “utilization data” may refer to any informationassociated with allocation, deployment, or utilization of resources on acloud computing system. For example, utilization data may refer tostates of utilization on a node cluster captured at different points intime (e.g., a snapshot of resource utilization). Examples of utilizationdata may include a number of nodes and/or node cores on a node clusterhaving virtual machines or other services thereon, a metric offragmentation or shape of resource utilization such as a number of emptynodes and/or percentage of node cores in use by virtual machines, andobserved trends of utilization over time (e.g., cross-day utilization,intra-day utilization). Utilization data may further include dataassociated with properties or characteristics of hardware and/orservices (e.g., virtual machines) on a node cluster. Utilization datamay refer to raw data and/or refined or extrapolated data that providesa description of resource utilization on a node cluster for a set ofcustomer deployments.

As will be discussed in further detail below, a cluster defragmentationmanagement system may generate or identify cluster features (or featuresignals) from the utilization data. The cluster features may refer toany signal or identifiable characteristic of customer deployments or ofa node cluster (e.g., hardware and/or software components of the nodecluster) that may be provided as an input to a model (e.g., a machinelearning model) for determining failure metrics for the node cluster(s).

Cluster features or feature signals may refer to different types ofcharacteristics or categories of features such as snapshot log data or autilization log including signals associated with utilization on thenode cluster. By way of example, and as will be discussed in furtherdetail below, these signals may refer to a current or recentavailability of empty server nodes on the node cluster, a differencebetween a current core utilization and a total capacity of compute coreson the node cluster, or a fragmentation metric based on a ratio ofavailable compute cores in a set of server nodes (e.g., occupied orpartially occupied nodes) and a total number of compute cores in the setof server nodes. As a further example, cluster features may refer toproperty log signals (e.g., characteristics associated with hardwaretypes and/or virtual machine types) and/or event log signals (e.g.,update request information).

As used herein, a “deployment,” “customer deployment,” or “tenantdeployment” may refer interchangeably to one or more associated servicesand allocations provided by a cloud computing system via a node cluster.For example, a deployment may refer to one or multiple services and/orapplications provided to or otherwise accessible to a customer (ormultiple associated customers) using computing resources of a nodecluster. A deployment may refer to one or multiple services providedbased on an initial deployment request. In one or more embodimentsdescribed herein, a deployment refers exclusively to related servicesand allocations within a single node cluster.

As used herein, a “current deployment” or “existing deployment” refersto a deployment that has been previously permitted and is currentlylocated or otherwise running within a node cluster. Thus, a “set ofexisting deployments” or a “set of current deployments” may refer to aset of one or multiple deployments that have been previously permittedand are currently located within and which may be eligible for upgradeor expansion, such as scaling in or scaling out resources within a nodecluster.

As used herein, a “core,” “compute core,” or “node core” may referinterchangeably to a computing resource or unit of computing resourcesprovided via a computing node (e.g., a server node) of a cloud computingsystem. A compute core may refer to a virtual core that makes use of thesame processor without interfering with other virtual cores operating inconjunction with the processor. Alternatively, a compute core may referto a physical core having a physical separation from other computecores. Compute cores implemented on one or across multiple server nodesmay refer to a variety of different cores having different sizes andcapabilities. A server node may include one or multiple compute coresimplemented thereon. Furthermore, a set of multiple cores may beallocated for hosting one or multiple virtual machines or othercloud-based services.

As used herein, an “expansion” or “deployment expansion” may refergenerally to an increase, decrease, or other change in utilization orallocation of resources on a cloud computing system for an existingdeployment. In one or more embodiments, an expansion may refer to anallocation of additional computing resources (e.g., server nodes, nodecores) for an existing deployment. In addition, or as an alternative, anexpansion may refer to any modification of resources allocated for acustomer, including a decrease in allocated resources and/or a change ina number of cores allocated for one or more virtual machines. Indeed, adeployment expansion may refer to any change in an existing deploymentresulting in an increase, decrease, or fragmented shape of resourceutilization on a node cluster for the associated deployment. In one ormore embodiments, an expansion may be a result of a request to modify asubscription for a customer corresponding to a current deployment on thenode cluster.

Additional detail will now be provided regarding a clusterdefragmentation management system and one or more resource managementsystems in relation to illustrative figures portraying exampleimplementations. For example, FIG. 1 illustrates an example environment100 including a cloud computing system 102. The cloud computing system102 may include any number of devices. For example, as shown in FIG. 1,the cloud computing system includes one or more server device(s) 104having a cluster defragmentation management system 106 implementedthereon. In addition to the server device(s) 104, the cloud computingsystem may include any number of node clusters 108 a-n. One or more ofthe node clusters 108 a-n may be grouped by geographic location (e.g., aregion of node clusters). In one or more embodiments, the node clusters108 a-n are implemented across multiple geographic locations (e.g., atdifferent datacenters or on different racks including one or multiplenode clusters).

Each of the node clusters 108 a-n may include a variety of server nodeshaving a number and variety of compute cores. In addition, one or morevirtual machines or other cloud computing resources and services may beimplemented on the compute cores of the server nodes. For example, asshown in FIG. 1, a first node cluster 108 a may include a resourcemanagement system 110 a tasked with managing resources of the first nodecluster 108 a. As will be discussed in further detail below, theresource management system 110 a may include a defragmentation enginefor executing or otherwise carrying out defragmentation instructions inaccordance with an identified severity level to defragment a computingcapacity on the node cluster 108 a.

As further shown in FIG. 1, the first node cluster 108 a may include afirst set of server nodes 112 a. Each node from the first set of servernodes 112 a may include one or more compute core(s) 114 a. One or moreof the compute cores 114 a may include virtual machines and/or othercloud computing services implemented thereon. In one or moreembodiments, the first node cluster 108 a may include allocatedresources and services for a set of customer deployments currentlydeployed on the node cluster 108 a. The server node(s) 112 a may includeany number and variety of compute cores 114 a. Moreover, the servernode(s) 112 a may host a number and a variety of virtual machines andother services. As shown in FIG. 1, the cloud computing system 102 mayinclude multiple node clusters 108 a-n. Each of the node clusters 108a-n may include a resource management system 110 a-n, server nodes 112a-n, and compute cores 114 a-n.

As shown in FIG. 1, the environment 100 may include a plurality ofclient devices 116 a-n in communication with the cloud computing system102 (e.g., in communication with different server nodes 112 a-n via anetwork 118). The client devices 116 a-n may refer to various types ofcomputing devices including, by way of example, mobile devices, desktopcomputers, server devices, or other types of computing devices. Thenetwork 118 may include one or multiple networks that use one or morecommunication platforms or technologies for transmitting data. Forexample, the network 118 may include the Internet or other data linkthat enables transport of electronic data between respective clientdevices 116 a-n and devices of the cloud computing system 102.

As mentioned above, one or more resources (e.g., virtual machines) of afirst node cluster 108 a (or other node cluster from the plurality ofnode clusters 108 a-n) may include resources including one or multiplecompute cores occupied or otherwise in use by a customer. For example, afirst deployment may refer to one or multiple virtual machines on thesame server node or across multiple server nodes that provides access toa large-scale computation application to a user of the first clientdevice 116 a (or multiple client devices). As another example, a seconddeployment may refer to one or more virtual machines on the same servernode or across multiple server nodes that provides access to a gamingapplication to a second client device 116 b (or multiple clientdevices).

As will be discussed in further detail below, the clusterdefragmentation management system 106 may collect utilization data forthe node clusters 108 a-n including features and characteristics ofcomputing resources (e.g., nodes and compute cores) that are allocated,occupied, or otherwise in use with respect to a set of existingdeployments. As will be discussed in further detail below, the clusterdefragmentation management system 106 can analyze the utilization datato generate cluster features and determine expansion failure metricsassociated with observed and/or predicted failure of deploymentexpansions on the node clusters 108 a-n. For example, the clusterdefragmentation management system 106 can collect utilization data andanalyze the utilization data to determine one or more failure metricsassociated with predicted and/or observed expansion failures on the nodeclusters 108 a-n.

As used herein, a failure metric may refer to a variety of indicatorsassociated with failure of one or more deployments on a node cluster.For example, a failure metric may refer to a prediction that a nodecluster will experience one or more expansion failures within anupcoming period of time. As another example, a failure metric may referto one or more observed failures that have occurred within a recentperiod of time. In one or more implementations, a failure metric mayrefer to an availability (e.g., a current availability) of empty servernodes (e.g., healthy empty nodes) on the node cluster. Additionalexamples of failure metrics will be discussed below in connection withillustrative examples.

In one or more embodiments, the cluster defragmentation managementsystem 106 utilizes failure metrics to generate defragmentationinstructions for a given node cluster. For example, where the clusterdefragmentation management system 106 determines that a first nodecluster 108 a is associated with failure metrics that indicate a highprobability of expansion failure during an upcoming period of time, thecluster defragmentation management system 106 can generatedefragmentation instructions indicating that the resource managementsystem 110 a on the first node cluster 108 a should implementdefragmentation at a high level of severity. Alternatively, where thecluster defragmentation management system 106 determines that a secondnode cluster 108 b includes failure metrics that indicate a lowprobability of expansion failure during an upcoming period of time, thecluster defragmentation management system 106 may generatedefragmentation instructions indicating that the resource managementsystem 110 b on the second node cluster 108 b should implementdefragmentation at a low or minimum level of severity.

In addition, and as will be discussed in further detail below, thecluster defragmentation management system 106 can receive one or moreadditional parameters or inputs for use in determining specificinstructions for defragmenting a capacity on a given node cluster. Forexample, the cluster defragmentation management system 106 may receiveone or more user inputs (e.g., from an administrator or domain levelexpert for one or more clusters of the cloud computing system 102)indicating one or more thresholds and/or cluster-specific fragmentationparameters. In determining specific defragmentation instructions, thecluster defragmentation management system 106 may consider a combinationof failure metrics and additional inputs (e.g., manual inputs) indetermining an appropriate severity level for defragmenting a computingcapacity on the node cluster(s).

As mentioned above, the cluster defragmentation management system 106can determine and generate defragmentation instructions that are uniqueto any number of node clusters 108 a-n. For example, the clusterdefragmentation management system 106 can collect utilization data fromeach of the node clusters 108 a-n and determine failure metrics for eachof the node clusters 108 a-n. In addition, the cluster defragmentationmanagement system 106 can receive additional instructions to modify orsupplement defragmentation instructions for any of the node clusters 108a-n to further refine a severity with which the resource managementsystems 110 a-n can carry out defragmentation on the respective nodeclusters 108 a-n.

In one or more embodiments, the cluster defragmentation managementsystem 106 is implemented as part of a more comprehensive centralresource system. For example, the cluster defragmentation managementsystem 106 may refer to a subsystem of a central resource system thatgenerates and provides other information such as policies regarding newallocations, predictions of various allocation failures, generalcapacity and utilization predictions, virtual migration impact metrics,or any other information related to the management of resources on thecloud computing system 102. Accordingly, while one or more embodimentsdescribed herein relate specifically to a cluster defragmentationmanagement system 106 that generates and implements defragmentationinstructions for the node clusters 108 a-n, it will be appreciated thatone or more additional systems and engines may similarly communicateinformation to the resource management systems 110 a-n for use inmanaging the resources and other aspects on the respective node clusters108 a-n.

FIG. 2 illustrates an example implementation in which the clusterdefragmentation management system 106 determines failure metrics for anexample node cluster and generates defragmentation instructions for thenode cluster based on the determined failure metrics. For example, FIG.2 illustrates an example implementation in which the clusterdefragmentation management system 106 evaluates utilization data for asingle node cluster 216 and determines an appropriate level of severitythat a defragmentation engine 218 on the node cluster 216 should use indefragmenting a capacity of server nodes on the node cluster 216.Features and characteristics discussed in connection with theillustrated example of FIG. 2 can similarly apply to any of the multiplenode clusters 108 a-n on the cloud computing system 102 discussed abovein connection with FIG. 1.

It will be noted that while FIGS. 1-2 illustrate features andfunctionality for preventing expansion failures on server nodes of anode cluster, features and functionality of the cluster defragmentationmanagement system 106 and resource management system 110 may similarlybe implemented in connection with a deployment on a different networkunit or organization of networked devices. For instance, while one ormore embodiments described herein relate to a node cluster, similarfeatures for preventing expansion failures on a node cluster maysimilarly apply to a specific server rack, a virtual network, anavailability zone, or set of computing resources including server nodesand compute cores capable of being used for deployment of virtualmachines thereon.

As shown in FIG. 2, the cluster defragmentation management system 106includes a failure prediction system 202 and a defragmentation manager204. As further shown, the failure prediction system 202 may include adata collection engine 206, a feature engineering manager 208, and afailure prediction model 210. Each of the components 206-210 of thefailure prediction system 202 may cooperatively collect and evaluateutilization data to determine a prediction (e.g., a probability score)associated with whether the node cluster 216 is expected to experienceexpansion failures over an upcoming period of time. For example, as willbe discussed in further detail below in connection with FIGS. 3 and 4A,the failure prediction system 202 can determine an estimated probabilitythat the node cluster 216 will experience one or more expansion failuresas a result of growth of one or more current deployments hosted by thenode cluster 216.

As further shown, defragmentation manager 204 may include an interfacemanager 212 and an instruction generator 214. Each of these components212-214 may cooperatively generate instructions for defragmentingresource capacity on the node cluster 216 based on a variety of signalsincluding one or more expansion failure metrics. For example, as will bediscussed in further detail below in connection with FIGS. 3 and 4B, thedefragmentation manager 204 can receive expansion failure metricsincluding a failure prediction, information indicating a current stateof fragmentation on the node cluster 216 (e.g., a number of observedexpansion failures, a current number of empty server nodes), andadditional utilization data to use in determining a severity level toapply by a defragmentation engine 218. Moreover, in one or moreembodiments, the defragmentation manager 204 receives one or more userinputs indicating modifications to one or more fragmentation parametersthat may be used to modify defragmentation instructions for the nodecluster 216.

As discussed above, the node cluster 216 may include a resourcemanagement system 110 implemented thereon. As shown in FIG. 2, theresource management system 110 may further include a defragmentationengine 218. As used herein, the defragmentation engine 218 may refer toa processing or orchestrating engine configured to implementinstructions to cause one or more modifications to virtual machines andserver nodes in a way that modifies distribution of capacity acrossnodes of the node cluster 216. For example, the defragmentation engine218 may orchestrate defragmentation in a variety of ways in accordancewith an identified severity level. This may include migrating (e.g.,live-migrating) virtual machines from one server node to another. Thismay include decommissioning one or more virtual machines and/or spinningup additional virtual machines elsewhere. Indeed, the defragmentationengine 218 may perform any number of defragmentation actions resultingin distribution of resource utilization across nodes of the node cluster216.

As mentioned above, the defragmentation engine 218 may orchestratedefragmentation in accordance with a determined severity level. As usedherein, a severity level may refer to a measure of aggressiveness ofredistributing or consolidating the resource load across nodes of thenode cluster 216. As an example, the defragmentation engine 218 mayperform defragmentation actions in accordance with a severity levelbased on an impact of performing the defragmentation actions on acustomer. For instance, where a defragmentation engine 218 is performingdefragmentation at a low severity level, the defragmentation engine 218may perform live migration on virtual machines where live migrating thevirtual machines would result in minimal impact to a customer (e.g., acustomer impact less than a minimum threshold). Alternatively, where thedefragmentation engine 218 is performing defragmentation at a highseverity level, the defragmentation engine 218 may perform livemigration aggressively and quickly with little or no consideration onwhether performing live migration will impact a customer. Additionaldetails and examples in connection with performing defragmentationactions in accordance with different severity levels will be discussedbelow in connection with FIGS. 3-4B.

While one or more embodiments described herein refer specifically tofeatures and functionalities of a cluster defragmentation managementsystem 106 and a resource management system 110, it will be understoodthat features and functionality described in connection with each of thesystems 106, 110 may similarly apply to one another. For instance, oneor more components of the cluster defragmentation management system 106may be implemented at the cluster level (e.g., as a sub-component of theresource management system 110). Conversely, one or more components orfeatures of the resource management system 110 may be implemented on thecluster defragmentation management system 106 or on a central resourcesystem hosted by the server device(s) 104 and which is configured toorchestrate defragmentation on a plurality of node clusters.

As further shown, the node cluster 216 may include any number andvariety of server nodes. For example, the node cluster 216 may includeoccupied nodes 220 in which compute cores 222 have virtual machines orother services implemented thereon. In particular, the occupied nodes220 may refer to fully occupied nodes in which all cores are occupied byone or more virtual machines hosted on the server nodes. The nodecluster 216 may also include empty nodes 224 having no virtual machinesdeployed thereon. Because the empty nodes 224 have no virtual machinesdeployed thereon, the empty nodes 224 may be used by the resourcemanagement system 110 for a variety of applications. For instance, theempty nodes 224 may be used as a target destination for any virtualmachine on the node cluster 216. Moreover, the empty nodes 224 may beused to perform repairs, updates, or any other operation on the nodecluster 216 where occupied or fragmented nodes may be incompatible orunavailable. In one or more embodiments, and as will be discussed infurther detail below, the resource management system 110 may mandate orhave a setting that mandates a minimum number of empty nodes 224 on thenode cluster 216 to ensure that the node cluster 216 be capable ofsupporting expansions as well as dealing with various emergencyscenarios such as a server rack going down unexpectedly (e.g., due to apower outage or other service interruption event). The node cluster 216may similarly have a target number of empty nodes corresponding to adesired number of empty nodes that ensure peak performance of the nodecluster 216.

As further shown, the node cluster 216 may include a number offragmented nodes 226. In particular, as shown in FIG. 2, the fragmentednodes 226 may include occupied compute cores 228 having virtual machinesdeployed thereon. In one or more embodiments, a virtual machine may bedeployed on multiple compute cores. The fragmented nodes 226 mayadditionally include empty cores 230 having no virtual machines deployedthereon. Where a fragmented node includes a number of empty corescapable of hosting a virtual machine, the virtual machine may bedeployed to the empty cores. However, where a fragmented node includesfewer empty cores than is needed to host a virtual machine, the virtualmachine would need to be deployed to a different node, such as an emptynode or another fragmented node having enough empty cores. As will bediscussed in further detail herein, the cluster defragmentationmanagement system 106 may determine a likelihood of expansion failuresbased on a number or percentage of compute cores occupied by virtualmachines as well as fragmentation characteristics of nodes on the nodecluster 216.

Each of the components of the cluster defragmentation management system106 and resource management system 110 may be in communication with eachother using any suitable communication technologies. In addition, whilecomponents of the systems 106, 110 are shown to be separate in FIG. 2,any of the components or subcomponents may be combined into fewercomponents, such as into a single component, or divided into morecomponents as may serve a particular implementation. As an illustrativeexample, the data collection engine 206 and/or feature engineeringmanager 208 may be implemented on different server devices of a cloudcomputing system as the failure prediction model 210.

In addition, the components of the systems 106, 110 may includehardware, software, or both. For example, the components of the systems106, 110 may include one or more instructions stored on acomputer-readable storage medium and executable by processors of one ormore computing devices. When executed by the one or more processors, thecomputer-executable instructions of one or more computing devices (e.g.,server device(s) 104, server nodes) can perform one or more methodsdescribed herein. Alternatively, the components of the systems 106, 110may include hardware, such as a special purpose processing device toperform a certain function or group of functions. Additionally, oralternatively, the components of the systems 106, 110 may include acombination of computer-executable instructions and hardware.

An example implementation of the cluster defragmentation managementsystem 106 and resource management system 110 will now be discussed inconnection with an example framework illustrated in FIG. 3. As mentionedabove, and as shown in FIG. 3, the cluster defragmentation managementsystem 106 may include a failure prediction system 202 and adefragmentation manager 204. In addition, the resource management system110 may include a defragmentation engine 218.

As shown in FIG. 3, the failure prediction system 202 can receivecluster data 302. The cluster data 302 may include observed data about anode cluster including one or more types of utilization data. By way ofexample and not limitation, the failure prediction system 202 canreceive cluster data including cluster property information, workloadinformation, a status of empty nodes (e.g., a number of healthy emptynodes), virtual machine lifetime information, policy limits applicableto the node cluster, and a fragmentation index or other metric(s) offragmentation across nodes of the node cluster. In one or moreembodiments, the cluster data 302 is received or otherwise accessed froma data store maintained by a central resource system configured tocollect utilization data and other data about a plurality of nodeclusters on the cloud computing system.

Based on the cluster data 302, the failure prediction system 202 cangenerate a failure prediction 304 indicating a level of risk or otherclassification for the node cluster. For example, the failure predictionsystem 202 may determine a risk of expansion failure based on theutilization data indicating a likelihood that a node cluster associatedwith the utilization data will experience an expansion failure in anupcoming period of time. In one or more embodiments, the failureprediction system 202 applies a failure prediction model (e.g., amachine learning model) to the utilization data to determine the failureprediction 304. Additional detail in connection with analyzing theutilization data and applying a failure prediction model to determine afailure prediction 304 is discussed below in connection with FIG. 4A.

As shown in FIG. 3, the failure prediction system 202 may provide thefailure prediction 304 to the defragmentation manager 204. Based on thefailure prediction 304, the defragmentation manager 204 can determine anappropriate level of severity that a defragmentation engine 218 shoulduse in implementing a defragmentation routine on a given node cluster.As shown in FIG. 3, in addition to the failure prediction 304, thedefragmentation manager 204 can receive one or more defragmentationparameters 306 to additionally consider in determining a level ofseverity and/or generating instructions for defragmenting a resourcecapacity of the node cluster. As mentioned above, and as will bediscussed in further detail below, the defragmentation parameters 306may refer to one or more received user inputs indicating one or moremetrics such as a target number of empty nodes or a modification to adetermined level of severity that the defragmentation manager 204 mayconsider in generating defragmentation instructions 308. Additionalinformation in connection with generating defragmentation instructions308 in view of a number of failure metrics and/or user inputs will bediscussed below in connection with FIG. 4B.

As shown in FIG. 3, the defragmentation manager 204 can generatedefragmentation instructions 308 based on one or more failure metricsincluding, by way of example, the failure prediction 304 and thedefragmentation parameters 306. As further shown, the defragmentationmanager 204 can provide the defragmentation instructions 308 to thedefragmentation engine 218 for further processing. As discussed aboveand as shown in FIG. 3, the defragmentation engine 218 may beimplemented at a cluster level while the failure prediction system 202and defragmentation manager 204 are implemented on a server device incommunication with multiple defragmentation engines on different nodeclusters of a cloud computing system 102.

As shown in FIG. 3, the defragmentation engine 218 can execute orotherwise implement the defragmentation instructions 308 to perform avariety of defragmentation actions 310 on a node cluster. In particular,the defragmentation engine 218 can perform a variety of actions onvirtual machines hosted by the node cluster such as live-migratingvirtual machines between server nodes to defragment the currentcomputing capacity on the node cluster. For example, the defragmentationengine 218 can live-migrate virtual machines to consolidate workloads onfragmented nodes to increase a number of empty nodes on the nodecluster. In one or more embodiments, the defragmentation engine 218continues performing defragmentation actions 310 until a target numberof healthy nodes are available on the node cluster.

As mentioned above, the defragmentation engine 218 can implement thedefragmentation actions 310 based on a severity level indicated by thedefragmentation instructions 308. As an example, where thedefragmentation instructions 308 indicate a low severity level (e.g.,based on a failure prediction 304 indicating a low probability ofexpansion failure), the defragmentation engine 218 may initiatelive-migration with a high or heavily weighted consideration to whetherlive-migrating a given virtual machine will have a negative customerimpact. This may involve selectively migrating virtual machines ofparticular types that may be live-migrated with little or negativeimpact on customer. For example, the defragmentation engine 218 maylimit performance of live-migration based on a low impact threshold suchthat the defragmentation engine 218 selectively live-migrates virtualmachines only where live-migrating the virtual machines is expected tohave a low or minimal impact to a customer. As a further example, thismay involve selectively migrating virtual machines for lower prioritycustomers while allowing virtual machines for higher priority customersto continue running on otherwise fragmented server nodes.

As another example, where the defragmentation instructions 308 indicatea high severity level (e.g., based on a failure prediction 304indicating a high probability of expansion failure), the defragmentationengine 218 may initiate live-migration with little consideration towhether live-migrating virtual machines will have a negative customerimpact. This may involve raising an impact threshold in determiningwhether to live-migrate a virtual machine. In one or moreimplementations, this may involve live-migrating virtual machinesbetween server nodes without any consideration to customer impact orwithout distinguishing between customers associated with high or lowpriority accounts.

In one or more embodiments, the defragmentation engine 218 modifies anexisting defragmentation routine based on defragmentation instructions308 received from the defragmentation manager 204. For example, in oneor more embodiments, the defragmentation engine 218 may continually runa low severity level routine that involves live-migrating virtualmachines while avoiding or otherwise limiting negative customer impact.The defragmentation engine 218 may change that routine to a higherseverity level, however, based on a failure prediction 304 and/ordefragmentation parameters 306 indicating that a higher level ofseverity in defragmenting a capacity of the node cluster should beapplied. Accordingly, in response to updated defragmentationinstructions 308, the defragmentation engine 218 may implement adefragmentation routine at a higher severity level based on updateddefragmentation instructions 308, which may be based on real-time (ornear real-time) observations of utilization activity on the nodecluster.

As shown in FIG. 3, one or more components of the clusterdefragmentation management system 106 may be self-evaluating. As anexample, in one or more embodiments, the defragmentation manager 204 mayprovide feedback data 312 to the failure prediction system 202 for usein determining future failure predictions. For instance, where one ormore defragmentation parameters 306 indicate a modification to a targetnumber of empty nodes or a modification to an indicated level ofseverity corresponding to a failure prediction 304, the feedback data312 may be used by the failure prediction system 202 to modify a failureprediction model in an effort to determine future instances of failurepredictions that align with the defragmentation parameters 306.

As another example, the failure prediction system 202 and/ordefragmentation manager 204 may receive updated cluster data 314including additional utilization information observed on the nodecluster. This updated cluster data 314 may refer to modifications to thecapacity of the node cluster as a result of the defragmentation actions310. In addition, the updated cluster data 314 may include observedexpansion failures and/or changed utilization patterns over time. In oneor more embodiments, the failure prediction system 202 and/ordefragmentation manager 204 may modify models (e.g., the failureprediction model) or algorithms implemented thereon to fine-tune futureinstances of the failure prediction 304 and/or defragmentationinstructions 308. In this manner, one or more components of the clusterdefragmentation management system 106 may improve over time inimplementing a defragmentation routine at an appropriate severity levelthat prevents expansion failures while minimizing a negative customerimpact caused by live-migrating virtual machines on the resourcemanagement system 110.

Additional detail in connection with one or more embodiments will now bediscussed in conjunction with FIGS. 4A-4B. In particular, FIG. 4Aillustrates an example workflow implemented by a failure predictionsystem 202 in accordance with one or more embodiments and which mayinclude similar features and functionality as the failure predictionsystem 202 discussed in FIG. 3. Further, FIG. 4B illustrates an exampleworkflow implemented by a defragmentation manager 204 anddefragmentation engine 218 in accordance with one or more embodimentsand which may include similar features and functionality as thecorresponding components discussed in FIG. 3.

As shown in FIG. 4A, a failure prediction system 202 may implement aworkflow that involves receiving and evaluating utilization data andgenerating a failure prediction metric in accordance with one or moreembodiments described herein. In particular, as shown in FIG. 4A, a datacollection engine 206 may receive observed cluster data 402 includingany information associated with utilization of resources as well asproperties and characteristics of devices and services of a nodecluster. While the data collection engine 206 may receive observedcluster data 402 from any number of node clusters, for ease inexplanation, the example in FIG. 4A will be discussed in connection withreceiving observed cluster data 402 for a single node cluster.

The data collection engine 206 can collect a variety of types ofutilization data. For example, the data collection engine 206 mayreceive a series of snapshot logs indicating states of resourceutilization on the node cluster over time. For example, the datacollection engine 206 may receive a snapshot log of data includingvarious types of information such as an availability of server nodes ata corresponding point in time, a difference between a current coreutilization on the node cluster and a total capacity of compute cores onthe node cluster, or a ratio of available compute cores in a set ofserver nodes and a total number of compute cores on the set of servernodes.

In addition to snapshot log data indicating states of resourceutilization over time, the data collection engine 206 can collectproperty log data including characteristics of hardware (e.g., hardwaretypes) on the node cluster as well as virtual machine types deployed onthe node cluster. The data collection engine 206 may further collectevent log data including update request information or other customerbehavior data associated with a set of deployments on the node cluster.In each of the above example, the data collection engine 206 may collectraw utilization data at points in time (e.g., at correspondingtimestamps) associated with utilization of resources and/or propertiesof devices and services on the node cluster. For example, the datacollection engine 206 may capture or otherwise obtain periodic snapshotsof utilization data for the node cluster at different points in time.

In one or more embodiments, the data collection engine 206 may sampleinformation at regular or irregular intervals. In one or moreimplementations, the data collection engine 206 collects utilizationinformation about a subset of nodes and/or cores rather than collectingcomprehensive information about each and every core or server node ofthe node cluster. Thus, in one or more embodiments, the data collectionengine 206 generates refined cluster data 404 that includes a morecomprehensive set of information (e.g. utilization data) for the nodecluster over a previous duration of time. The data collection engine 206may generate the refined cluster data 404 in a variety of ways.

For example, in one or more embodiments, the data collection engine 206performs a statistical analysis and quantity measurement of the rawcluster data to identify errors and implications of the data. In one ormore embodiments, the data collection engine 206 applies an adaptiveinterpolation approach to fill in missing or incomplete data associatedwith the utilization and/or characteristics of nodes and/or virtualmachines of the node cluster. This may include observing trends of anumber of compute cores occupied by virtual machines and otherinformation indicating trends of compute capacity and fragmentationcharacteristics of the node cluster. Indeed, the data collection engine206 may employ a number of interpolation approaches to generate therefined cluster data 404.

As an illustrative example, where one or more occupied nodes andfragmented nodes have historically been occupied by the same number ofvirtual machines for a stable period of time and where a number of emptynodes remains relatively unchanged over time, the data collection engine206 may extrapolate utilization data and other information based on amean, median, or mode value of core capacity and utilization for thenode of the node cluster. As another example, where historical dataassociated with utilization of cluster resources fluctuates in apredictable or periodic way, the data collection engine 206 can apply aone or more regression models to predict fluctuating utilizationinformation over time. For example, where utilization statisticsincrease or otherwise fluctuate on weekends as a result of higherutilization by customers for certain types of virtual machines, the datacollection engine 206 can apply a regression model to the historicaldata to extrapolate similar fluctuations on weekends or other days ofthe week. The data collection engine 206 may similarly apply aregression or other model over longer periods of time to identifylong-term trends, such as increased utilization due to deploymentexpansions and/or a change in fragmentation characteristics over time.

As a further example, the data collection engine 206 can employ a morecomplex model to predict non-obvious utilization trends than mean,median, mode, or simple regression models. For example, the datacollection engine 206 can employ a machine learning model, algorithm, orother deep learning model(s) trained to extrapolate utilization data andother information where no obvious pattern exists in the utilization ofcluster resources over time. In one or more embodiments, the datacollection engine 206 employs a processing model trained to extrapolatethe refined cluster data by applying each of the processing models(e.g., mean, mode, mean regression, complex model) depending on thetrends of portions of the raw data collected by the data collectionengine 206.

In addition to identifying trends of deployment growth and expansionscorresponding to periodic increases over short period of time (e.g.,hourly, daily), the data collection engine 206 can extrapolate oridentify growth trends over longer periods of time (e.g., one or moreweeks or months). For example, in addition to identifying periodictrends including expansion and contraction of deployments from day today, the data collection engine 206 may identify gradual growth overtime as expansions occur and deployments gradually grow closer to fullcapacity of the node cluster. In addition, the data collection engine206 can observe or identify a gradual change in fragmentation of thecapacity based on lifetimes of virtual machines expiring and/orcustomers unsubscribing and/or downgrading deployments over time.

As shown in FIG. 4A, the data collection engine 206 can provide therefined cluster data 404 to a feature engineering manager 208 forfurther processing. In particular, the feature engineering manager 208can receive the refined cluster data 404 and generate cluster features(e.g., feature signals) to provide as input to a failure predictionmodel 210. For example, the feature engineering manager 208 can evaluatethe refined cluster data and determine any number of feature signalsthat the failure prediction model 210 is trained to receive or otherwiserecognizes as valid input to use in generating a failure prediction forthe node cluster. These feature signals may relate to one or more typesof the utilization data as well as characteristics of hardware and/orservices on the node cluster.

For example, the feature engineering manager 208 can generate any numberof cluster features (e.g., feature signals) from the refined clusterdata that correspond or correlate to a target metric. In particular, thefeature engineering manager 208 can process the received cluster dataand generate feature signals that correspond to whether one or moreexpansions for a set of deployments on a node cluster will fail. In oneor more embodiments, the feature engineering manager 208 generates thefeature signals based exclusively on the received refined cluster data404. Alternatively, in one or more embodiments, the feature engineeringmanager 208 further refines the cluster data (e.g., combines data fromsnapshots of the utilization data over time) to generate any number offeature signals to provide as input to the failure prediction model 210.

As shown in FIG. 4A, the feature engineering manager 208 can generate avariety of feature signals associated with utilization of resources onthe node cluster. The feature engineering manager 208 may employ avariety of feature engineering approaches, including both data-drivenand context-driven approaches. For example, the feature engineeringmanager 208 can generate signals associated with utilization (e.g., adata driven approach) and/or signals associated with cluster propertiesof the node cluster that utilize domain knowledge of the node cluster,existing deployments, and/or the cloud computing platform.

Indeed, the feature engineering manager 208 can generate any number anda wide variety of feature signals for use in determining a probabilitythat a set of deployments on the node cluster will experience one ormore (or a predetermined threshold of) expansion failures over a periodof time (e.g., an upcoming threshold period of time). In addition, thefeature signals may include a wide variety of signals associated withdifferent trends or data points. In one or more embodiments, the featureengineering manager 208 may generate thousands of different featuresignals having variable levels of correlation to whether a set ofdeployments will experience an expansion failure within a thresholdperiod of time.

By way of example and not limitation, the feature signals may includesignals associated with time based log data (e.g., a snapshot log).Examples of these types of signals may include an identified state ortrend of allocable healthy empty nodes (e.g., a count or trend ofhealthy empty nodes within a node cluster), a utilization delta value(e.g., difference between current utilization and a maximum utilizationthat a node cluster can reach), a fragmentation index value (e.g., ameasure of fragmentation within a node cluster, such as the sum ofavailable cores in each used node divided by a total number of coresfrom these used or partially used nodes), or a tenant hourly expansionvalue (e.g., an hourly scale up of physical cores for a deployment overa predetermined period, such as an hour).

As another example, the feature signals may include signals associatedwith property log data. Examples of these types of signals may includestock keeping unit (SKU) type (e.g., an identification of a hardwaregeneration of nodes and/or cores), a cluster type (e.g., a type ofvirtual machine family that can be supported by nodes on the nodecluster, such as a graphic processing unit or various types of computeservices), an account type (e.g., internal or external customer), or anoffer type (e.g., a free trial, a premium subscriber). Another exampleproperty log data signal may include an identified region or size of thecluster (e.g., U.S. East, Europe West).

As a further example, the feature signals may include signals associatedwith event log data including information associated with expansionsand/or expansion requests for deployments on a node cluster. Examples ofevent log data signals may include instances of expansion core requests(e.g., a number of physical cores requested by one or more observedexpansion operations) and/or instances of requests that were notfulfilled (e.g., expansions or number of cores that the node clusterfailed to fulfill).

The above instances of feature signals are provided by way of exampleand not limitation. It will be appreciated that the feature engineeringmanager 208 may generate any number of features that the failureprediction model 210 is trained to receive as input. In one or moreembodiments, the feature engineering manager 208 may be configured togenerate new types of feature signals over time as expansion failuresare observed and further correlations are determined between differentcombinations of utilization data and expansion failures. In one or moreembodiments, the feature engineering manager 208 may identifycombinations of multiple feature signals having a high correlation toexpansion failures and further generate additional feature signals basedon combinations of the utilization data and/or discrete feature signals.

In one or more embodiments, the feature engineering manager 208generates a set of distinct features associated with a particular nodecluster (e.g., for each node cluster from a plurality of node clusterson the cloud computing system). Nevertheless, in one or moreembodiments, the feature engineering manager 208 selectively identifiesa subset of the feature signals to provide as input to the failureprediction model 210. For example, the feature engineering manager 208may employ a two-step feature selection approach for selecting signalsto provide as inputs. As a first step, the feature engineering manager208 can leverage classic feature selection to select candidate features,such as feature importance ranking, feature filtering via stepwiseregression, or feature penalization through regularization. The featureengineering manager 208 can selectively evaluate top feature signals ormore important feature signals (e.g., feature signals having a highdegree of correlation with expansion failures) while discarding orotherwise minimizing the impact of less important feature signals.

As shown in FIG. 3, the feature engineering manager 208 can provide aset of feature signals 406 to the failure prediction model 210. Uponreceiving the feature signals, the failure prediction model 210 cangenerate an output including a failure prediction. The failureprediction may include an indication (e.g., a value or category)associated with an estimated likelihood that the node cluster will haveone or more expansion failures for an existing set of deployments over apredetermined period of time (e.g., within 1-2 days, within a week).

In one or more embodiments, the failure prediction model 210 outputs afailure prediction metric including a category that characterizes alikelihood of expansion failures. For instance, the failure predictionmodel 210 can generate a classification of low, medium, or highcorresponding to low, medium, and high risks of expansion failure.Alternatively, in one or more embodiments, the failure prediction model210 simply generates a numerical value associated with a probability orestimated likelihood that the node cluster will experience expansionfailure(s) within a predetermined period of time.

In one or more embodiments, the failure prediction model 210 calculatesa probability score based on a combination of feature signals. Thefailure prediction model 210 may further determine a categorycorresponding to a risk of expansion failure based on the probabilityscore. Alternatively, the failure prediction model 210 can provide afailure probability score to the defragmentation manager 204 todetermine a corresponding risk or risk category. In either case, thefailure prediction model 210 may determine the risk category based on acomparison of the probability score to one or more risk thresholds. Asan example, in one or more embodiments, the failure prediction model 210determines the failure probability metric including a risk metric inaccordance with the following equation:

${{Risk}\mspace{14mu}{of}\mspace{14mu}{Upgrade}\mspace{14mu}{Failure}_{\tau}} = \left\{ \begin{matrix}{{{low},}\ } & {p_{i} < \alpha} \\{{medium},} & {\ {Otherwise}} \\{{{high},}\ } & {p_{i} > \beta}\end{matrix} \right.$

where p_(i) represents the predicted confidence of a single labelclassification (e.g., failure v. non-failure) and where α and β refer totuned thresholds based on a target fragmentation or goal associated withdefragmenting a capacity on the node cluster. For example, node clusterswith high risk of expansion failures may be optimized for extremely highground truth failures within the corresponding risk category (e.g.,bucket) while node clusters with low risk of expansion failures may beoptimized for significantly low ground truth failures.

As shown in FIG. 4A, the failure prediction model 210 may consider afeature list 408 including features associated with variable levels ofimportance. To illustrate, the failure prediction model 210 may considera feature list 408 including each of any number of feature signals thatthe failure prediction model 210 is trained to receive as input andprocess in accordance with training of the failure prediction model 210.In the example of FIG. 4A, the feature list 408 includes feature signalsand associated categories of importance that correspond to a measure ofimportance of the respective feature. For ease in explanation, each ofthe feature signals shown have a high, medium, or low level ofimportance corresponding to a degree of correlation between the featuresignals and whether an expansion probability is predicted to occur onthe node cluster. In one or more embodiments, the failure predictionmodel 210 generates the feature list 408 based on training data used totrain the failure prediction model 210.

In one or more embodiments, the failure prediction model 210 may receiveadditional parameters and/or training data for use in determining thefailure prediction metric 410. For example, as discussed in above inconnection with FIG. 3, the failure prediction model 210 can receivefeedback data and/or updated cluster data that may be used to fine-tuneor refine the failure prediction model 210 to more accurately determinethe failure prediction model for future states of the node cluster. Inone or more embodiments, the failure prediction model 210 may receivemodel parameters such as a user input or other value indicating amodified foal of the node cluster, such as a modification to a targetnumber of empty nodes that may influence a determination of a riskcategory for the node cluster.

In one or more embodiments, the failure prediction model 210 refers to amachine learning model, deep learning model, or other type of model fordetermining the failure prediction metric 410 for the node cluster. Inone or more embodiments, the failure prediction model 210 includes orutilizes or utilizes a decision tree model. As shown in FIG. 4A, thefailure prediction model 210 can provide the failure prediction metric410 to the defragmentation manager 204 for further processing.

FIG. 4B shows an example continuation of the workflow discussed in FIG.4A including an interface manager 212 and an instruction generator 214.As will be discussed in further detail, the interface manager 212 and aninstruction generator 214 can receive the failure prediction metric 410(and additional information) and cooperatively determine a set ofinstructions for a plurality of node clusters. In particular, while FIG.4A illustrates an example in which data is collected and analyzed for asingle node cluster, the failure prediction system 202 may similarlyevaluate cluster data and generate failure prediction metrics for eachof a plurality of node clusters.

As shown in FIG. 4B, the instruction generator 214 may receive thefailure prediction metric(s) 410 for a plurality of node clusters. Inaccordance with one or more embodiments discussed above, the failureprediction metric(s) 410 may include an indicated probability or riskcategory associated with an estimated likelihood that a respective nodecluster will experience one or more expansion failures within anupcoming period of time.

In addition to the failure prediction metric(s) 410, the instructiongenerator 214 may receive additional failure metrics 412 for use ingenerating defragmentation instructions. For example, instructiongenerator 214 may receive additional failure metrics 412 including anindication of whether expansion failures are already happening on thenode cluster(s). In one or more embodiments, the instruction generator214 receives an additional failure metric including a current state ofempty nodes on the node cluster(s). The additional failure metrics maybe provided from the failure prediction system 202 and/or the nodecluster itself.

In one or more embodiments, the failure prediction metrics 410 and theadditional failure metrics 412 are provided to an interface manager 212for use in generating a workbench interface 414 including a compilationof relevant data that may be presented to a user. For example, as shownin FIG. 4B, the interface manager 212 may provide the workbenchinterface 414 via a graphical user interface of a client device (e.g.,an administrator device). As shown in FIG. 4B, the workbench interface414 may include a presentation of any number of failure metricsassociated with corresponding node clusters of the cloud computingsystem.

As shown in FIG. 4B, the workbench interface 414 may include a clusteridentifier indicating a name, region, or other identifier of each nodecluster from a plurality of node cluster. The workbench interface 414may further include a listing of failure predictions determined for eachof the node clusters. For instance, in the example shown in FIG. 4B, thefailure prediction model 210 may have output a high risk categoryfailure prediction for a first cluster node (cluster A) and low riskcategory failure predictions for a second and third node cluster(clusters B-C). The workbench interface 414 may alternatively include aprobability score, risk category, and/or any additional informationassociated with the failure prediction output by the failure predictionmodel 210. While FIG. 4B illustrates one example implementation of theworkbench interface 414, the workbench interface 414 may include anynumber of parameters and signals associated with any number of nodeclusters.

As further shown, the workbench interface 414 may include a listing ofempty node targets for each of the node clusters. As shown in FIG. 4B,the target number of empty nodes may differ from cluster to cluster. Inthe illustrative example shown in FIG. 4B, the first node cluster mayhave an empty node target of eighteen nodes, the second node cluster mayhave an empty node target of twelve nodes, and the third node clustermay have an empty node target of ten nodes. These targets may beselected based on characteristics of the corresponding node clusters,such types of virtual machines running thereon and/or a total number ofserver nodes on the respective node clusters.

As further shown, the workbench interface 414 may include a listing ofdetermined severity levels to apply in generating defragmentationinstructions for the respective node clusters. In one or moreembodiments, the severity levels are determined based on thecorresponding failure predictions. The severity levels may also bedetermined based on a combination of the failure predictions incombination with additional parameters, such as the additional failuremetrics, the empty node target(s) and any additional information thatmay be provided within the workbench interface 414.

One or more parameters of the workbench interface 414 may be modifiedbased on received user input. For example, as shown in FIG. 4B, theworkbench interface 414 includes selectable options for both the emptynode target category as well as the severity level that enables anindividual (e.g., a customer or domain level expert) to modify one ormore of the values within the workbench interface 414. For instance,where an individual is not concerned about customer impact associatedwith live-migrating virtual machines, the individual may modify one ofthe lower severity levels to a higher severity level. Alternatively,where a user desires to raise or lower the target number of empty nodes,the user may modify one or more of the empty node target values withinthe workbench interface 414.

In one or more embodiments, modifying the values of the workbenchinterface 414 may cause a feedback loop that causes one or moreadditional values to change. As an example, in response to detecting achange in an empty node target value for the second node cluster, thedefragmentation manager 204 may provide an indication of the change tothe failure prediction system 202. In response, the failure predictionsystem 202 may update feature signals and generate an updated failureprediction that classifies the second node cluster as higher risk ofexpansion failure, which may be associated with a higher severity level.Other examples may involve different combinations of changes within theworkbench interface 414.

In one or more embodiments, the workbench interface 414 may indicate aranking of priority for each of the node clusters identifying an orderor priority for generating and/or implementing defragmentationinstructions for the set of node clusters. For instance, where a nodecluster is hosting virtual machines for high priority customers or whereexpansion failures would pose a significant threat to important data orservices, the interface manager 212 may include an indication of thehigher importance or higher ranking for the relevant node cluster(s). Inone or more embodiments, a user may manually indicate one or more nodeclusters that should have a higher priority than others within thelisted set of node clusters.

In one or more embodiments, this ranking may be considered inselectively determining a subset of the node clusters that should bedefragmented. For example, where the cloud computing system has aprocessing budget that limits a quantity of nodes or clusters that canbe defragmented over a period of time, the ranking may be used toprioritize implementation of defragmentation instructions to ensure thatthose node clusters having a higher ranking will be defragmented asquickly as possible (within the allocated budget). In one or moreembodiments, the node clusters may be defragmented in a specific orderbased on the priority or ranking indicated within the workbenchinterface 414.

As shown in FIG. 4B, the instruction generator 214 may receiveinformation from the interface manager 212 (e.g., modifications to oneor more parameters) in addition to the failure prediction metric(s) 410and additional failure metrics 412 and generate defragmentationinstructions for each of a plurality of node clusters. In particular, asshown in FIG. 4B, the instruction generator 214 may generate a first setof defragmentation instructions 416 a for a first node cluster 418 a(cluster A), a second set of defragmentation instructions 416 b for asecond node cluster 418 b (cluster B), and a third set ofdefragmentation instructions 416 c for a third node cluster 418 c(cluster C).

In accordance with one or more embodiments described herein, each of thesets of defragmentation instructions 416 a-c may include indicatedlevels of severity for performing defragmentation on the respective nodeclusters 418 a-c. For instance, in the example shown in FIG. 4B, thefirst set of defragmentation instructions 416 a may indicate a “3”severity level indicating to the defragmentation engine 218 a to carryout a defragmentation routine at a severity of level of 3 (e.g., a highor medium severity level). The second set of defragmentationinstructions 416 b may indicate a “1” severity level indicating to asecond defragmentation engine 218 b to carry out a defragmentationroutine at a severity of “1” (e.g., a low or default severity level).Similarly, the third set of defragmentation instructions 416 c mayindicate a “1” severity level indicating to a third defragmentationengine 218 c to carry out a defragmentation routine at a severity levelof “1.”

Turning now to FIG. 5, this figure illustrates an example flowchartincluding a series of acts for determining a failure prediction andgenerating defragmentation instructions for a node cluster. While FIG. 5illustrates acts according to one or more embodiments, alternativeembodiments may omit, add to, reorder, and/or modify any of the actsshown in FIG. 5. The acts of FIG. 5 can be performed as part of amethod. Alternatively, a non-transitory computer-readable medium caninclude instructions that, when executed by one or more processors,cause a computing device (e.g., a server device) to perform the acts ofFIG. 5. In still further embodiments, a system can perform the acts ofFIG. 5.

As shown in FIG. 5, the series of acts 500 may include an act 510 ofidentifying cluster features for a node cluster based on utilizationdata for the node cluster. For example, in one or more embodiments, theact 510 involves identifying a plurality of cluster features for a nodecluster based on utilization data for the node cluster where the nodecluster comprises a grouping of server nodes on a cloud computingsystem.

In one or more embodiments, the cluster features include one or more ofa current availability of empty server nodes on the node cluster, adifference between a current core utilization on the node cluster and atotal capacity of compute cores on the node cluster, and/or afragmentation metric based on a ratio of available compute cores in aset of server nodes and a total number of compute cores on the set ofserver nodes. The cluster features may further include one or more ofproperty log signals including characteristics associated with hardwaretypes of the node cluster and virtual machine types deployed on the nodecluster and/or event log signals including update request informationassociated with the set of deployments on the node cluster.

As further shown, the series of acts 500 may include an act 520 ofdetermining one or more expansion failure metrics based on the clusterfeatures including an expansion failure prediction for a set ofdeployments on the node cluster. For example, in one or moreembodiments, the act 520 involves determining one or more expansionfailure metrics for the node cluster based on the identified pluralityof cluster features where at least one of the expansion failure metricsincludes an expansion failure prediction for a set of deployments on thenode cluster.

In one or more embodiments, the expansion failure prediction includes arisk classification for the node cluster indicating an estimatedprobability that the set of deployments on the node cluster willexperience one or more expansion failures within a threshold period oftime. In one or more embodiments, the risk classification includes arisk category from a plurality of possible risk categories where each ofthe risk categories corresponding to a different defragmentationseverity level for performing the one or more defragmentation actions onthe node cluster.

In one or more embodiments, the one or more expansion failure metricsincludes one or more of an indication of one or more expansion failuresthat have occurred within a threshold period of time and/or a currentavailability of empty server nodes on the node cluster. In one or moreembodiments, the expansion failure metrics includes one or morecluster-specific fragmentation parameters associated with a thresholdperformance level for the node cluster. The cluster-specificfragmentation parameters may include one or more of a minimumavailability of empty server nodes on the node cluster or a targetavailability of empty server nodes on the node cluster.

As further shown, the series of acts 500 includes an act 530 ofgenerating defragmentation instructions indicating a defragmentationseverity level for defragmenting a resource capacity on the node clusterbased on the one or more expansion failure metrics. For example, in oneor more embodiments, the act 530 involves generating defragmentationinstructions applicable to the node cluster based on the one or moreexpansion failure metrics where the defragmentation instructionsindicate a defragmentation severity level for performing one or moredefragmentation actions on the node cluster.

In one or more embodiments, receiving a user input involves identifyingone or more cluster-specific fragmentation parameters (as indicatedabove). Further, in one or more embodiments, generating thedefragmentation instructions includes determining the defragmentationseverity level based on a combination of the expansion failureprediction and the received user input identifying the one or morecluster-specific fragmentation parameters.

As further shown, the series of acts 500 includes an act 540 ofproviding defragmentation instructions to a server device forimplementing the defragmentation instructions on the node cluster. Forexample, in one or more embodiments, the act 540 involves providing thedefragmentation instructions to a server device associated with the nodecluster for implementing the one or more defragmentation actions onserver nodes of the node cluster.

In one or more embodiments, the series of acts 500 includes identifyingadditional cluster features for a second node cluster based onadditional utilization data for the second node cluster. The series ofacts 500 may also include determining additional expansion failuremetrics for the node cluster based on the identified additional clusterfeatures. The series of acts 500 may also include generating additionaldefragmentation instructions applicable to the additional node clusterbased on the additional expansion failure metrics.

In one or more embodiments, the defragmentation instructions and theadditional defragmentation instructions each include an indicated levelof priority for performing defragmentation on the node cluster and theadditional node cluster. Further, in one or more embodiments, the seriesof acts 500 includes determining an order of implementingdefragmentation actions on the node cluster and the additional nodecluster based on the indicated level of priority for each of the nodecluster and the additional node cluster.

FIG. 6 illustrates certain components that may be included within acomputer system 600. One or more computer systems 600 may be used toimplement the various devices, components, and systems described herein.

The computer system 600 includes a processor 601. The processor 601 maybe a general-purpose single- or multi-chip microprocessor (e.g., anAdvanced RISC (Reduced Instruction Set Computer) Machine (ARM)), aspecial purpose microprocessor (e.g., a digital signal processor (DSP)),a microcontroller, a programmable gate array, etc. The processor 601 maybe referred to as a central processing unit (CPU). Although just asingle processor 601 is shown in the computer system 600 of FIG. 6, inan alternative configuration, a combination of processors (e.g., an ARMand DSP) could be used.

The computer system 600 also includes memory 603 in electroniccommunication with the processor 601. The memory 603 may be anyelectronic component capable of storing electronic information. Forexample, the memory 603 may be embodied as random access memory (RAM),read-only memory (ROM), magnetic disk storage media, optical storagemedia, flash memory devices in RAM, on-board memory included with theprocessor, erasable programmable read-only memory (EPROM), electricallyerasable programmable read-only memory (EEPROM) memory, registers, andso forth, including combinations thereof.

Instructions 605 and data 607 may be stored in the memory 603. Theinstructions 605 may be executable by the processor 601 to implementsome or all of the functionality disclosed herein. Executing theinstructions 605 may involve the use of the data 607 that is stored inthe memory 603. Any of the various examples of modules and componentsdescribed herein may be implemented, partially or wholly, asinstructions 605 stored in memory 603 and executed by the processor 601.Any of the various examples of data described herein may be among thedata 607 that is stored in memory 603 and used during execution of theinstructions 605 by the processor 601.

A computer system 600 may also include one or more communicationinterfaces 609 for communicating with other electronic devices. Thecommunication interface(s) 609 may be based on wired communicationtechnology, wireless communication technology, or both. Some examples ofcommunication interfaces 609 include a Universal Serial Bus (USB), anEthernet adapter, a wireless adapter that operates in accordance with anInstitute of Electrical and Electronics Engineers (IEEE) 802.11 wirelesscommunication protocol, a Bluetooth® wireless communication adapter, andan infrared (IR) communication port.

A computer system 600 may also include one or more input devices 611 andone or more output devices 613. Some examples of input devices 611include a keyboard, mouse, microphone, remote control device, button,joystick, trackball, touchpad, and lightpen. Some examples of outputdevices 613 include a speaker and a printer. One specific type of outputdevice that is typically included in a computer system 600 is a displaydevice 615. Display devices 615 used with embodiments disclosed hereinmay utilize any suitable image projection technology, such as liquidcrystal display (LCD), light-emitting diode (LED), gas plasma,electroluminescence, or the like. A display controller 617 may also beprovided, for converting data 607 stored in the memory 603 into text,graphics, and/or moving images (as appropriate) shown on the displaydevice 615.

The various components of the computer system 600 may be coupledtogether by one or more buses, which may include a power bus, a controlsignal bus, a status signal bus, a data bus, etc. For the sake ofclarity, the various buses are illustrated in FIG. 6 as a bus system619.

The techniques described herein may be implemented in hardware,software, firmware, or any combination thereof, unless specificallydescribed as being implemented in a specific manner. Any featuresdescribed as modules, components, or the like may also be implementedtogether in an integrated logic device or separately as discrete butinteroperable logic devices. If implemented in software, the techniquesmay be realized at least in part by a non-transitory processor-readablestorage medium comprising instructions that, when executed by at leastone processor, perform one or more of the methods described herein. Theinstructions may be organized into routines, programs, objects,components, data structures, etc., which may perform particular tasksand/or implement particular data types, and which may be combined ordistributed as desired in various embodiments.

As used herein, non-transitory computer-readable storage media (devices)may include RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g.,based on RAM), Flash memory, phase-change memory (“PCM”), other types ofmemory, other optical disk storage, magnetic disk storage or othermagnetic storage devices, or any other medium which can be used to storedesired program code means in the form of computer-executableinstructions or data structures and which can be accessed by a generalpurpose or special purpose computer.

The steps and/or actions of the methods described herein may beinterchanged with one another without departing from the scope of theclaims. In other words, unless a specific order of steps or actions isrequired for proper operation of the method that is being described, theorder and/or use of specific steps and/or actions may be modifiedwithout departing from the scope of the claims.

The term “determining” encompasses a wide variety of actions and,therefore, “determining” can include calculating, computing, processing,deriving, investigating, looking up (e.g., looking up in a table, adatabase or another data structure), ascertaining and the like. Also,“determining” can include receiving (e.g., receiving information),accessing (e.g., accessing data in a memory) and the like. Also,“determining” can include resolving, selecting, choosing, establishingand the like.

The terms “comprising,” “including,” and “having” are intended to beinclusive and mean that there may be additional elements other than thelisted elements. Additionally, it should be understood that referencesto “one embodiment” or “an embodiment” of the present disclosure are notintended to be interpreted as excluding the existence of additionalembodiments that also incorporate the recited features. For example, anyelement or feature described in relation to an embodiment herein may becombinable with any element or feature of any other embodiment describedherein, where compatible.

The present disclosure may be embodied in other specific forms withoutdeparting from its spirit or characteristics. The described embodimentsare to be considered as illustrative and not restrictive. The scope ofthe disclosure is, therefore, indicated by the appended claims ratherthan by the foregoing description. Changes that come within the meaningand range of equivalency of the claims are to be embraced within theirscope.

What is claimed is:
 1. A method, comprising: identifying a plurality ofcluster features for a node cluster based on utilization data for thenode cluster, wherein the node cluster comprises a grouping of servernodes on a cloud computing system; determining one or more expansionfailure metrics for the node cluster based on the identified pluralityof cluster features, at least one of the expansion failure metricsincluding an expansion failure prediction for a set of deployments onthe node cluster; generating defragmentation instructions applicable tothe node cluster based on the one or more expansion failure metrics, thedefragmentation instructions indicating a defragmentation severity levelfor performing one or more defragmentation actions on the node cluster;and providing the defragmentation instructions to a server deviceassociated with the node cluster for implementing the one or moredefragmentation actions on server nodes of the node cluster.
 2. Themethod of claim 1, wherein the cluster features include one or more of:a current availability of empty server nodes on the node cluster; adifference between a current core utilization on the node cluster and atotal capacity of compute cores on the node cluster; or a fragmentationmetric based on a ratio of available compute cores in a set of servernodes and a total number of compute cores on the set of server nodes. 3.The method of claim 2, wherein the cluster features include one or moreof: property log signals including characteristics associated withhardware types of the node cluster and virtual machine types deployed onthe node cluster; or event log signals including update requestinformation associated with the set of deployments on the node cluster.4. The method of claim 1, wherein the expansion failure predictionincludes a risk classification for the node cluster, the riskclassification indicating an estimated probability that the set ofdeployments on the node cluster will experience one or more expansionfailures within a threshold period of time.
 5. The method of claim 4,wherein the risk classification includes a risk category from aplurality of possible risk categories, each of the risk categoriescorresponding to a different defragmentation severity level forperforming the one or more defragmentation actions on the node cluster.6. The method of claim 1, wherein the one or more expansion failuremetrics further includes one or more of: an indication of one or moreexpansion failures that have occurred within a threshold period of time;or a current availability of empty server nodes on the node cluster. 7.The method of claim 1, wherein the one or more expansion failure metricsincludes one or more cluster-specific fragmentation parametersassociated with a threshold performance level for the node cluster, theone or more cluster-specific fragmentation parameters including one ormore of: a minimum availability of empty server nodes on the nodecluster; or a target availability of empty server nodes on the nodecluster.
 8. The method of claim 7, further comprising: receiving a userinput identifying the one or more cluster-specific fragmentationparameters, wherein generating the defragmentation instructionscomprises determining the defragmentation severity level based on acombination of the expansion failure prediction and the received userinput identifying the one or more cluster-specific fragmentationparameters.
 9. The method of claim 1, further comprising: identifyingadditional cluster features for a second node cluster based onadditional utilization data for the second node cluster; determiningadditional expansion failure metrics for the node cluster based on theidentified additional cluster features; and generating additionaldefragmentation instructions applicable to the additional node clusterbased on the additional expansion failure metrics.
 10. The method ofclaim 9, wherein the defragmentation instructions and the additionaldefragmentation instructions each include an indicated level of priorityfor performing defragmentation on the node cluster and the additionalnode cluster, and wherein the method further comprises determining anorder of implementing defragmentation actions on the node cluster andthe additional node cluster based on the indicated level of priority foreach of the node cluster and the additional node cluster.
 11. A system,comprising: one or more processors; memory in communication with the oneor more processors; instructions stored in the memory, the instructionsbeing executable by the one or more processors to: identify a pluralityof cluster features for a node cluster based on utilization data for thenode cluster, wherein the node cluster comprises a grouping of servernodes on a cloud computing system; determine one or more expansionfailure metrics for the node cluster based on the identified pluralityof cluster features, at least one of the expansion failure metricsincluding an expansion failure prediction for a set of deployments onthe node cluster; generate defragmentation instructions applicable tothe node cluster based on the one or more expansion failure metrics, thedefragmentation instructions indicating a defragmentation severity levelfor performing one or more defragmentation actions on the node cluster;and provide the defragmentation instructions to a server deviceassociated with the node cluster for implementing the one or moredefragmentation actions on server nodes of the node cluster.
 12. Thesystem of claim 11, wherein the cluster features include one or more of:a current availability of empty server nodes on the node cluster; adifference between a current core utilization on the node cluster and atotal capacity of compute cores on the node cluster; a fragmentationmetric based on a ratio of available compute cores in a set of servernodes and a total number of compute cores on the set of server nodes;property log signals including characteristics associated with hardwaretypes of the node cluster and virtual machine types deployed on the nodecluster; or event log signals including update request informationassociated with the set of deployments on the node cluster.
 13. Thesystem of claim 11, wherein the expansion failure prediction includes arisk classification for the node cluster, the risk classificationindicating an estimated probability that the set of deployments on thenode cluster will experience one or more expansion failures within athreshold period of time, and wherein the risk classification includes arisk category from a plurality of possible risk categories, each of therisk categories corresponding to a different defragmentation severitylevel for performing the one or more defragmentation actions on the nodecluster.
 14. The system of claim 11, wherein the one or more expansionfailure metrics further includes one or more of: an indication of one ormore expansion failures that have occurred within a threshold period oftime; or a current availability of empty server nodes on the nodecluster.
 15. The system of claim 11, wherein the one or more failuremetrics includes one or more cluster-specific fragmentation parametersincluding one or more of a minimum availability of empty server nodes onthe node cluster or a target availability of empty server nodes on thenode cluster, and further comprising instructions being executable bythe one or more processors to: receive a user input identifying the oneor more cluster-specific fragmentation parameters, wherein generatingthe defragmentation instructions comprises determining thedefragmentation severity level based on a combination of the expansionfailure prediction and the received user input identifying the one ormore cluster-specific fragmentation parameters.
 16. A non-transitorycomputer readable medium storing instructions thereon that, whenexecuted by one or more processors, causes a computing device to:identify a plurality of cluster features for a node cluster based onutilization data for the node cluster, wherein the node clustercomprises a grouping of server nodes on a cloud computing system;determine one or more expansion failure metrics for the node clusterbased on the identified plurality of cluster features, at least one ofthe expansion failure metrics including an expansion failure predictionfor a set of deployments on the node cluster; generate defragmentationinstructions applicable to the node cluster based on the one or moreexpansion failure metrics, the defragmentation instructions indicating adefragmentation severity level for performing one or moredefragmentation actions on the node cluster; and provide thedefragmentation instructions to a server device associated with the nodecluster for implementing the one or more defragmentation actions onserver nodes of the node cluster.
 17. The non-transitory computerreadable medium of claim 16, wherein the cluster features include one ormore of: a current availability of empty server nodes on the nodecluster; a difference between a current core utilization on the nodecluster and a total capacity of compute cores on the node cluster; afragmentation metric based on a ratio of available compute cores in aset of server nodes and a total number of compute cores on the set ofserver nodes; property log signals including characteristics associatedwith hardware types of the node cluster and virtual machine typesdeployed on the node cluster; or event log signals including updaterequest information associated with the set of deployments on the nodecluster.
 18. The non-transitory computer readable medium of claim 16,wherein the expansion failure prediction includes a risk classificationfor the node cluster, the risk classification indicating an estimatedprobability that the set of deployments on the node cluster willexperience one or more expansion failures within a threshold period oftime, and wherein the risk classification includes a risk category froma plurality of possible risk categories, each of the risk categoriescorresponding to a different defragmentation severity level forperforming the one or more defragmentation actions on the node cluster.19. The non-transitory computer readable medium of claim 16, wherein theone or more expansion failure metrics further includes one or more of:an indication of one or more expansion failures that have occurredwithin a threshold period of time; or a current availability of emptyserver nodes on the node cluster.
 20. The non-transitory computerreadable medium of claim 16, wherein the one or more failure metricsincludes one or more cluster-specific fragmentation parameters includingone or more of a minimum availability of empty server nodes on the nodecluster or a target availability of empty server nodes on the nodecluster, wherein the instructions, when executed by the one or moreprocessors, causes the computing device to: receive a user inputidentifying the one or more cluster-specific fragmentation parameters,wherein generating the defragmentation instructions comprisesdetermining the defragmentation severity level based on a combination ofthe expansion failure prediction and the received user input identifyingthe one or more cluster-specific fragmentation parameters.